Get an answer from the Determinations Server Assess Request

Get an answer from the Determinations Server Assess request

What do you want to do?

Get an attribute as an answer

Get a relationship as an answer

Process multiple determinations within the same Assess request

Handle errors or warnings returned by the Determinations Server

Obtain a decision report from a web service

Specify outcomes for all instances of a given entity using the Outcome option

Get an attribute as an answer

You can get the answer to an attribute from the Oracle Determinations Server by using an Assess operation. Typically this attribute would be an inferred goal of a rulebase. In order to get an answer for this attribute goal you will need to provide sufficient information in the Assess operation for the answer to be inferred.

In both the generic and specific interfaces, you can ask for the value of the attribute by specifying an outcome style (outcome-style) instead of supplying a value. An outcome style tells the assess operation that you are asking for a value rather than setting one.

See also: Important Note: do not set value and specify outcome style for same attribute.

 

In the example above, the attribute element with an outcome-style is inside the entity element for client-100064. This means that I am requesting the value of the attribute client_is_eligible for the client identified in my assess request by the id client-100064. The outcome-style has been specified to be value-only, meaning I am only interested in the value. Alternatively you could specify an outcome-style of decision-report or base-attributes if you wanted the answer reported with a decision report.

In the assess response, you will find all attribute elements with an outcome-style now contain the inferred value of that attribute.

As an alternative to supplying the outcome style, we can supply both the known-outcome-style and unknown-outcome-style. This allows you to control the content of the response depending on whether the inferred attribute is known or unknown. In the example below we are again requesting the value of client_is_eligible for client instance client-100064. If the value of the attribute is unknown, we want a decision report. If the value of the attribute is known, we are only interested in the value:

 

Use of the specific format is very similar. The outcome-style (or both known-outcome-style and unknown-outcome-style) is specified for the element representing the attribute that we are interested in to indicate that the Determinations Server should put the value in the response:

 

 

 

Get a relationship as an answer

In the same way that you can ask for the value of an attribute as answer, you can also ask for the value of an inferred relationship. This is also done through the Assess operation, by specifying an outcome-style (or known-outcome-style and unknown-outcome-style) in the request.

 

 

As with attributes (see above), you can specify the outcome style to be the value (in this case all targets of the inferred relationship) or the value and a decision report.

In the assess response, you will find all relationship elements with outcome styles specified populated with all the targets of that relationship.

 

 

In the example response, we can see that the inferred relationship is known for the client, and that there are two eligible targets, identified by their id’s.

Use of the specific format is very similar. The outcome-style (or both known-outcome-style and unknown-outcome-style) is specified for the element representing the relationship that we are interested in to indicate that the Determinations Server should put the targets in the response:

 

 


Process multiple determinations within the same Assess request

The Determinations Server is able to process multiple determinations within the same Assess request. To do this you must:

  1. Design your rulebase to concurrently determine multiple outcomes.
  2. At runtime, construct your request to send all the entities you want to reason on, and all the outcomes that you want.

Rulebase Design

You can design a rulebase in such a way that it can make multiple determinations concurrently if the determinations are attributes or, less commonly, inferred relationships belonging to a non-singleton (and not the global) entity.

Once the outcomes belong to an entity, it is possible to create multiple entities and infer the values for all entities at once.

Example

In a Human Resources department, we want to determine the number of days of leave per year an employee is eligible for. We also want to determine if that person is eligible for long service leave. Both these outcomes are based on the number of years the employee has served in the company.

This rulebase can be found in the OPA runtime directory at: examples\rulebases\compiled\EmployeeLeave.zip

Employee Attributes
Attribute Type
Date joined company Base level (input)
The employee is eligible for long service leave Inferred (outcome)
The number of days of leave per year Inferred (outcome)

 

If we decide that the employee is the global entity, and the attributes are created against this entity, then we can only infer one employee’s outcomes per session, as we can only have one global entity.

However, if we create an entity "the employee" we can then have many employees in the rulebase, and we can effectively run a batch job, getting many outcomes within in the same session and think cycle.

Assess request at runtime

If the rulebase has been designed along the principles above, we can use a single Assess request to get multiple outcomes.

This can be done with the Determinations Server, and it is also possible to do this against the Determinations Engine API directly. In both cases the principle is:

  1. Create a session with multiple entity instances
  2. Provide all the input data necessary to determine the outcomes
  3. Retrieve outcomes.

See also:

Assess Request and Response Elements

Example: Assess Request xml

Example: Assess Response xml

Handle errors or warnings returned by the Determinations Server

The Determinations Server will return Error and Warning events that may happen during an assess operation.

For Warninngs, you must specify in the assess-request that you want any warning returned. You can do this by setting the optional “show-events” attribute of the assess-request “config” element. This is the same for both the Specific and Generic service.

 

 

When show events has been set to true, any warning events will display at the top of the assess-response.

 

 

A warning event is always returned with the entity and a decision report attached.

For error events, no configuration is needed. Error events will always return a SOAP Fault if and error is raised in the inferencing.

 

Obtain a decision report from a web service

Get a decision report showing the rules used to reach a decision

When you request an outcome from the Determinations Server, you have control over what information is returned:

 

You can also ask for different information to be returned depending on the whether the outcome in known or unknown; for example, if the outcome is known, you may just want the value, but, if the outcome is unknown, you may want a full decision report.

When you request an attribute or relationship outcome you can specify what information you want displayed by setting the following XML attributes on the attribute or relationship element in the Assess request.

outcome-style:

this attribute controls the style of the outcome generally (regardless of when it is known or unknown.

known-outcome-style:

this attribute controls the style of the outcome when the outcome is known.

unknown-outcome-style:

this attribute controls the style of the outcome when the outcome is known.

 

For every outcome, you must specify either the outcome-style, or both the known-outcome-style and unknown-outcome-style.

The valid values for outcome styles are value-only, decision-report and base-attributes.

value-only

will return only the value for the outcome.

decision-report

will return a full decision report including all inferred attributes and relationships relationships that are relevant to the outcome.

base-attributes

will return a decision report, but only base level (non-inferred) attributes and relationships that are relevant to the outcome.

 

Response with decision report

In the example response below, you can see that the requested attribute eligible_teenage_child_allowance is unknown.

The decision report explains that the contributing entities, attributes and relationships are:

 

By examining the decision report you can see that the reason that the attribute is unknown is because the child’s age in unknown for child_3.

 


Control the information included in a decision report

There are several ways in which you can control information included in a decision report. The first way is to set the silent and invisible options on the attribute (see authoring > attributes > silent and invisible).

In addition to controlling the attributes that appear through their silent/invisible properties when authoring the rulebase, for the Determinations Server you can also set a decision report to base-attributes. This is specified when you request an attribute or relationship outcome in an Assess operation. When this value is set for the decision report style no inferred attributes will be returned, only base level attributes.

See Assess Operation Request and Response Elements for more information on outcome-styles.

Specify outcomes for all instances of a given entity using the Outcome option

In the example that follows, we specify the attribute outcomes "B.Benefit_Amount" and "monthly_benefit_timeline" as well as the relationship outcome "the_payments" for every single instance of the entity "the_benefit". The outcome-style is used to specify the level of detail that will be provided in the decision report; a full decision report will returned.

The following describes each of the elements used in the above example (more information can be found in Assess Operation Request and Response Elements in the Technical Reference section):

outcome

Specifies the assess outcomes.

entity id

Specifies the public name of the entity.

attribute-outcome id

Corresponds to the public name of the attribute.

relationship-outcome id

Corresponds to the public name of the relationship.

outcome-style

This is the default outcome-style to use whether known or unknown. The outcome style attribute can be "value-only" (no decision report, just the value), "base-attributes" (a decision reports showing the relevant attributes, but only the base level ones), and "decision-report" a full decision report.